引言：你以為案件在處理中，其實它正在「漂流」

在後端架構的日常中，我們最常聽到的專案痛點莫過於：「那個案件現在在哪裡？」、「補件補了兩週，為什麼沒人追蹤？」或是「這筆核准到底是 AI 算的還是人點的？」。當系統缺乏結構化的狀態管理時，案件的位置往往只存在於相關人員的「模糊印象」裡。

這種「等待」的真相，本質上是「權責不明」。在缺乏治理手段的開發環境中，「等待節點」極易演變成無人值守的荒原。要解決這項治理痼疾，架構師的任務是將口頭上的「辦公室公約」，轉化為具備強制力的程式邏輯——也就是透過「狀態機（State Machine）」將治理紅線直接刻進系統的骨架裡。

第一大亮點：等待不該是狀態，而是一場「有主人的接力」

將流程「狀態化」是落實治理的第一步。在 Day 10 的分析中，我們發現所謂的「沉底案件」，多半是因為「案件沒有狀態，導致等待沒有主人」。

狀態契約：讓換手成為責任的移交 狀態機的核心不在於畫圖，而是在於定義「狀態契約」。透過將流程參數化，我們能有效消除「轉寄即卸責（O3）」的組織病病：

• 轉換即留痕： 每一次狀態轉換（Transition）都必須強制記錄四個維度：從哪個狀態轉換到哪個狀態、誰執行的（Actor）、執行者類型（Human, AI, 或 System）以及轉換原因（Reason）。這確保了每一秒鐘的等待都有跡可循。
• 治理參數落地： 在本系統的設計中，Received、Processing、Awaiting Review、Approved 與 Completed 等七個狀態被嚴格定義。每個非終態（Non-terminal State）都綁定了明確的「主人（Owner）」、服務水準協議（SLA）以及逾時後的「升級對象（Escalation Target）」。
  

第二大亮點：程式碼裡的紅線：AI 絕不能自己核准自己

在 AI 驅動的治理系統中，最危險的莫過於自動化邏輯逾越了人工決策的邊界。如果治理僅僅依賴文件規範，而沒有在程式層級設限，系統隨時會面臨失控。

> 如果任何程式碼都能把案件轉成「已核准」，那 AI 建議與人工決策的界線只是文件上的一句話。

嚴格准入：將公約演化為會拋錯的程式碼 為了守住這條紅線，我們在狀態機中導入了 HUMAN_ONLY 轉換集合的概念。

• 硬性阻斷： 對於「核准（Approve）」、「退回（Return）」與「失敗重啟（Restart）」這三類涉及核心權責的動作，系統會檢查 actor_type。
• 拋錯機制： 若 AI 或系統排程企圖觸發上述轉換，系統會立即拋出 TransitionError 並阻斷程序。透過這種方式，我們將「AI 僅供建議」從虛無飄渺的原則，轉化為無法逾越的程式契約。

第三大亮點：重新定義失敗：它不是墳墓，而是通往重啟的門

在傳統流程設計中，「Failed（處理失敗）」往往是案件的終點站或垃圾桶。但在高階治理架構下，失敗狀態應被視為一個「等待人工接管的臨時站」。

P7 雙向門：失敗狀態的三大屬性 我們將處理失敗定義為「P7 雙向門（Two-way Door）」機制，強調流程雖然受阻，但必須具備受控的重啟路徑：

1. 有明確主人： 失敗後案件自動歸屬於收件檢視人。
2. 有時限壓力： 設定 8 小時的人工接管 SLA，確保問題不被掩蓋。
3. 有升級機制： 若逾時未處理，系統將自動向上呈報至部門主管。 這扇門是「雙向」的：它阻斷了錯誤的自動化延伸，但保留了由「人」確認原因後手動重啟流程的唯一路徑。

第四大亮點：稽核留痕的陷阱：被「共享」改寫的歷史

在實作狀態機時，一個細微的技術疏忽就可能讓整個治理體系崩潰。在測試過程中，我們發現了一個極具啟發性的錯誤：稽核紀錄的不可變性（Immutability）遭到破壞。

不可變性之痛：Pydantic model_copy 的淺拷貝教訓 在開發初期，我們使用 Pydantic 的 model_copy 方法來產生狀態轉換後的物件。然而，model_copy 預設執行的是「淺拷貝（Shallow Copy）」。這導致新舊兩個案件物件實際上共享了同一個歷史紀錄清單（List）。當系統往新物件寫入一筆轉換紀錄時，舊物件的「歷史」竟然也被同步改寫了。 這種「歷史會隨動作而改變」的情況在金融稽核中是致命的。我們最終將邏輯修正為強制建立新清單：history = [*case.history, record]。這再次證明了一件事：「不可變不是預設，是要自己掙來的」。

第五大亮點：讓測試成為治理的守門員（Meta-testing）

當系統規模擴大，如何確保未來的開發者不會遺漏這些治理規則？答案是將治理邏輯轉化為「Meta 測試（Meta-testing）」。

P6 協議落地：自動化的守護者 我們將 P6 治理協議（每個狀態必須有主人、SLA 與升級路徑）直接寫進測試套件中。這個測試會遍歷系統內所有的狀態枚舉，一旦發現任何一個非終態缺少關鍵治理參數，測試就會噴出失敗訊息。這種做法的價值在於「預防性治理」：任何不符合契約的修改，在進入營運階段前就會被 CI/CD 流程攔截。

結語：從「說到」到「做到」的技術距離

狀態機不只是一個程式碼模式，它是「治理邏輯」的具體實現。在這次的開發中，我們透過 19 項針對性測試，結合既有的基礎，達成了全套 92 項測試通過的指標。這代表每一條合法的轉換、每一筆不可篡改的紀錄，以及每一個人工決策點，都獲得了程式等級的保證。

當我們在談論 AI 治理時，最關鍵的問題在於：你的系統是依靠員工的自覺，還是依靠一套無法被逾越的程式契約？從「文件上的規範」到「程式碼裡的紅線」，這段技術距離的長短，決定了一個治理系統的真正成敗。